The chief weakness of the OSI model is that it only describes a small part of the network infrastructure and does so in operational terms (i.e. how it is done rather than what is done). Such a description forces us to describe important technologies such as Software Defined Networking and Virtual Private Networks as second class objects that merely emulate the 'proper' functionality.
To provide a comprehensive description of the Internet as it is today we need to consider both the protocol stack that describes the messages that are sent and the routing, naming and discovery services that decide _where_ the messages are sent.
Following the object oriented approach, we represent both parts of the architecture as objects as follows:
[Internet1.png] DNS Discovery ------> Application | V DNS Resolution ------> Presentation | V Transport | V BGP (ASN) ------> Network | V BGP (Path) ------> Link | V PhysicalNote that unlike the received Internet architectural model there are separate Transport and Presentation layers for reasons that are explained later.
At each layer in the stack we have a pattern in which each layer in the protocol stack is represented by a protocol object that exposes a message interface to the layers above and below it and a mapping object.
[Internet2.png] Upper Layer | V (Object exposes this interface) (Mapping) ------> Object | V (Object consumes this interface)Since it is the interfaces rather than the network layers that are important, it is necessary to have a vocabulary for identifying interfaces. This presents a problem as each layer in the stack has an upper and a lower interface. It is rather inconvenient to keep referring to the interface between the Application and the Presentation layers as the Application/Presentation layer interface but we certainly don't want to introduce a new set of terms to identify the interfaces.
For convenience therefore, we refer to each interface by the name of the lower object in the stack. This provides consistency with existing practice of referring to the topmost interface to the program code as the Application Interface. The Application/Presentation interface is therefor the Presentation interface and so on.
Each message interface consists of two parts, a message header which describes where and how the message is to be directed and the payload. In the traditional description of the architecture it is usual to describe the payload as 'data' but this is a mistake as only the application layer message payload is pure data. The payload of each lower layer is the header and payload of the layer above.
At the architectural level we are interested only in the information that is passed between the network layers rather than the syntax. Thus the term 'header' is used to refer to the information in the message that is not part of the payload whether it appears at the start of the message or the end.
As previously argued, the Internet architecture is not just described by Internet messages, the infrastructure that directs messages to their intended destination is equally important.
At each layer in the protocol stack the destination of a message is represented by a different type of identifier which become gradually more abstract and more specific to a particular information resource.
In the protocol stack these identifiers are:
The mapping infrastructure provides a translation between the identifier used in the upper layer to that in the lower.
The upper layer identifier of a protocol object is always more abstract or more specific than the lower. At the lowest physical layer, the Internet consists of many of switches connected by cables. When a switch receives a packet of data on one of its inbound ports it must decide whether to forward it to an outbound port and if so which one. At the uppermost layer a URL describes a _how_ and _where_ to obtain a specific resource.
For clarity we require that each layer in the stack involve exactly one mapping between identifiers. This in turn requires us to distinguish the Presentation and Transport layers and the Network and Data Link layers.
Many protocol objects that are not part of the network stack follow the same 'T-pattern' of transforming a message under the control of a mapping infrastructure but with the difference that the upper layer need not be more abstract than the lower.
For example an IP tunneling protocol such as an IPSEC VPN sits at the Transport interface, exposing and consuming a Transport interface.
[Internet3.png] | V [Transport Interface] Configuration -----> VPN | V [Transport Interface] ~~~~ The robustness of this model is proved by its ability to describe even satirical protocol proposals such as [RFC1149] and [RFC3093]. The case of RFC3093 (Firewall Enhancement Protocol/FEP) is particularly interesting as it describes TCP over HTTP, an approach that has actually seen widespread use. The T-pattern for FEP inverts the normal stack layering, exposing a Transport interface and consuming an Application interface. While it is clear that such an approach can be made to work, the T-pattern makes clear the 'last resort' nature of such approaches. ~~~~ [Internet4.png] | V [Transport Interface] Configuration -----> FET | V [Application Interface]Since many parts of a URI are implicit from the context in which it is used, it is best practice when designing a user interface to permit or possibly require the use of abbreviated forms. The use of a mail client that required the user to type mailto:alice@example.com rather than alice@example.com would be rather tiresome.
For the same reason many of the upper level identifier spaces encapsulate some or all of the lower identifier spaces as constants. For example, [~RFC5952] describes the mapping of the IPv6 address space to the DNS namespace as a text string.
To build security into the Internet architecture we need to define identifiers for cryptographic keys.
Combining a key identifier with a protocol identifier creates an identifier that describes how to locate and authenticate the resource identified. These are called strong identifiers and they play a major role in the re-architecting of the Internet to build security into its lowest layers.
Each type of Internet identifier is supported by an Internet infrastructure that provides a mapping to a more concrete form of identifier.
The modern Internet makes use of two mapping infrastructures, BGP and DNS, each of which supports multiple protocol stack layers.
The Internet routing infrastructure uses a two step approach to direct packets to their intended destination. Each Internet Service Provider that connects to the Internet is issued one or more Autonomous System Numbers (ASNs) which represent groups of IP addresses that are to be routed in the same direction.
The mapping of IP address ranges to ASNs is, or at least should be global. The choice of whether and where to route an inbound packet is local.
Both types of routing information is shared through a decentralized, peer-to-peer infrastructure using the Border Gateway Protocol (BGP).
While these two routing was originally conflated as a single protocol layer, the Network layer. Properly describing the role of BGP since requires us to distinguish between two types of mapping:
Again, the OSI model conveniently provides an established name with rather different semantics, the Data Link. Fortunately, the OSI networking stack has been defunct for a sufficiently long time that the term can now be used without risk of confusion.
Like the BGP, the DNS supports two stack layers that are conflated in the usual Internet model: Presentation and Application. Unlike the BGP, these two functions are not sharply distinguished by function.
From an early stage, the architects of DNS have insisted on a division of concerns between DNS Resource Records that make statements about names (including mapping names to other names) and those that map names to addresses. In a properly configured DNS server there are only two types of resource record that can properly map a DNS name to an IP address, A (IPv4) and AAAA (IPv6).
Although current day use of the DNS at the Application layer is limited, proposals are frequently made to expand this use. In particular the addition of DNSSEC to DNS makes it possible to use the DNS to provide protection against downgrade attack.
Although the primary purpose of the architectural model is descriptive rather than normative, an architectural model provides a useful reference point for discussing new proposals and the technology approaches that are appropriate to them.
Earlier we saw how the T-Pattern for FEP shows that it is practical but not desirable except as a last resort. The architectural model can help illustrate the design tradeoffs between different implementation architectures as well.
For example, what mapping infrastructures should the new DNS Privacy protocol rely on? What interfaces should these infrastructures be allowed to consume. If we are proposing a replacement for the DNS client-resolver protocol that provides mapping services the Presentation layer, consuming any interface above the Transport layer will introduce an abstraction inversion like we see in FEP. While this may not disqualify a proposal (it is easier to configure a service by DNS name than IP address) it is a cost that needs to be properly considered.
The architectural guide can also provide a guide to the appropriate choice of syntax. IETF practices has generally encouraged the use of text based (i.e. human readable) formats and binary formats at the Presentation layer and below.
The architecture model illustrates several security issues. Each of the mapping infrastructures on the left hand side of the diagram represents a potential point of attack or control.
The issue of control is frequently overlooked in security discussions but it is the most important question of all. The chief reason that the Internet is not supported by a comprehensive security infrastructure is not a lack of technology but the problem of who can be trusted to govern the control points.
Security always entails a transfer of power. While this transfer is usually beneficial to the receiver it is frequently to the disadvantage of other parties.
The mapping infrastructures each transform one form of identifier to another. It is this process of transformation that gives semantics to the identifier. The URI http://example.com/ has the semantic of locating a particular Web site because the DNS infrastructure maps the label example.com to a particular IP address which the BGP infrastructure maps to an Autonomous System Number and then to a sequence of physical links.
It is widely acknowledged that absent appropriate cryptographic countermeasures, control of any one the mapping infrastructures allows an adversary to perform confidentiality or integrity attacks. While these are important security concerns, the Internet is now a critical infrastructure on which every other infrastructure critical to the survival of our civilization depends. Availability of service is thus a critical concern but unfortunately not one that our existing cryptographic approaches provide a solution for.